Virtual private local area network services (VPLS) and pseudowires were created to overcome the problems of Ethernet loops and the Spanning Tree Protocol (STP). VPLS provides the option of multiple paths and eliminates delays and stoppages that often occur in STP-based networks. In Ethernet networks there is no time-to-live (TFL) in the Ethernet frames, creating a critical problem when there are loops in the network. Traffic will go around the loop forever, eventually congesting all the links on the loop and causing the network to collapse. To break these loops, STP was developed. However, STP converges slowly, resulting in network interruptions every time there is a change in the network topology. Furthermore, STP breaks loops by setting some links as “blocking” or inactive. This means that much of the capacity put into the network cannot be used. Instead it sits idle, waiting for a failure to occur.
VPLS was developed to create highly-reliable wide-area Ethernet networks. VPLS runs on top of pseudowires. A pseudowire emulates a transmission protocol. As one of ordinary skill would understand, pseudowire technology is the technique of carrying non-IP traffic over MPLS or IP tunnels.
For example, in the case of an Ethernet pseudowire in a VPLS network, the Ethernet pseudowire emulates an Ethernet connection by encapsulating an Ethernet frame into a multi-protocol label switching (MPLS) packet. The pseudowire includes two levels of encapsulation. At the first level, the Ethernet frame is wrapped in an inner label. The inner label determines the service that the pseudowire belongs to and is used at transmitting and receiving ends to demultiplex multiple pseudowires and find the correct switching context for the underlying traffic. The second encapsulation is an outer label which can be a multiprotocol label switching (MPLS) label, an IP header, or any one of the IP capsulations, such as GRE or IPSec.
The VPLS network uses the outer label to transmit the frame to a destination such as a router or MPLS switch. When the frame arrives at the destination, the destination strips the outer label and looks at the inner label. The inner label, which is a service label, indicates a particular service that the destination is configured to perform. The destination then switches the inner label to the particular service.
For example, a service may be Ethernet switching where the service label indicates which local Ethernet switching table/context to use. An underlying Ethernet destination MAC address is looked up in the Ethernet switching table to determine which port, and which Ethernet encapsulation to use in forwarding the frame.
FIG. 1A illustrates an example of a conventional VPLS network. The VPLS network 10 may include two nodes 20 and 30 connected together through an IP/MPLS network 40. Each of the nodes 20 and 30 is provided with at least one service which is identified by the value of the service label (e.g., service-ID). Each of the nodes 20 and 30 includes a service distribution point (SDP) 25 and 35, respectively. The service distribution points 25 and 35 allow the nodes 20 and 30 to link together through the IP/MPLS network 40.
Customer access ports 50 may access the node 20 through a service access point (SAP) 55. Similarly customer access ports 60 may access the node 30 though a SAP 65.
In VPLS, an interior gateway protocol (IGP), such as open shortest path first (OSPF) or intermediate system to intermediate system (ISIS) is brought up between the nodes in the network providing the VPLS service. The IGP allows the network to discover its topology, the shortest paths between each of the nodes, and automatically reroute around failures in the network. Furthermore, SAPs are added for local attachments at the end of the network. As understood by one of ordinary skill in the art, a SAP is a provisioning construct that is used to define the attached service. For example, the SAP may be used to define an Ethernet service attaching to the VPLS service with a particular virtual local area network identification (VLAN ID).
A carrier VPLS network is generally implemented by establishing a SDP configuration with other end nodes. A SDP is a provisioning construct that is used to abstract the method of getting from one provider edge (PE) at a node to another PE at another node. More specifically, the SDP ties a service to far end SAPs without having to specifically define the far end SAPs. The PE may be a router at the edge of a provider's network, for example.
Second, the SDP is bound to a label switched path (LSP), if MPLS is used, or an IP tunnel, such as GRE. In effect, the SDP defines what outer encapsulation a service will use to get from one PE to another. A separate SDP may be created for each PE pair.
Third, the VPLS service is configured. A VPLS service may be configured by entering into each PE router, the appropriate service configuration. The appropriate service configuration includes the local and remote virtual circuit identification (VC-ID) values which determine the inner label values, and setting up other specific values required for the particular service.
Lastly, mesh-SDP configurations are configured inside the VPLS service by using Targeted Label Distribution Protocol (T-LDP) to exchange labels.
Border Gateway Protocol (BGP) and Remote Authentication Dial In User Service (RADIUS) can be adapted and used to improve the automation of a VPLS configuration.
BGP handles automating peer discovery as well as signaling virtual circuit (VC) labels between peers. However, BGP is a large and complicated protocol. Furthermore, when BGP is used for VPLS, a transport tunnel network setup needs to be configured through other means, as well as any traffic optimization. In addition, BGP is a protocol that is familiar only to large network carriers. Most enterprise networks are completely or mostly unfamiliar with BGP.
RADIUS is used to automate VPLS peer discovery. Each PE may query a RADIUS server for a list of all of the peers in a VPLS network. Generally, peers may include PEs that have the same service configured. However, RADIUS is not fully automatic and requires an administrator to dedicate a server and program all the host addresses for the PE devices, the desired service labels, and the correct customer connection information. Furthermore, RADIUS does not automatically update with new PE information and each PE in a VPLS network will need to know the server's address and authentication information.
A VPLS network may often be difficult to set up. VPLS networks require expertise and knowledge to effectively create, deploy and administer. For example, inner and outer labels need to be configured, service parameters need to be set up and transport tunnels need to be defined via SDP configuration.
For a carrier that employs hundreds of people that are network experts, and has extensive support systems, setting up a VPLS network may be done easily.
However, enterprise environments such as law firms and hospitals typically have a limited IT staff. Moreover, those employed on the IT staff usually tend to be generalists and are not specialized. The complexity of VPLS limits the adoption of VPLS in enterprises.